First, let’s be clear that plugins in JADE can communicate, and generally very easily so. However, before we dive into some details, let’s observe that generally there are two core messaging paradigms in the universe: request-response and publish-subscribe. The former (request-response) involves sending a message and then waiting (perhaps only as long as a specified timeout) for a response. The latter (publish-subscribe) is a bit simpler in the sense that a publisher will publish data (when it has data to publish, often at some specified rate) to anyone who has “subscribed”.
With that in mind, JADE has built-in capabilities to make publish-subscribe communication incredibly simple, where plugins that want to subscribe to data (and of course handle those incoming messages) can simply declare that they subscribe to any number of other plugins which may publish data (we’ll say more about this below). A classic case for publish-subscribe semantics is a control or display plugin subscribing to data published by one or more data acquisition or instrument plugins. For example, an XY Chart plugin instance may subscribe to a Serial Publisher instance in order to display the data acquired over that serial port.
So what about request-response message in JADE? Well, plugins may communicate using request-response semantics but that feature would be provided by the plugins themselves and is not “automagically” baked into JADE via simple configuration like the publish-subscribe capabilities described herein.
Specifying that we want our XY Chart instance to subscribe to, say, a Serial Publisher instance is easy. We simply include the instance name of the Serial Publisher instance in the XY Chart’s subscribesTo array in configuration. That’s all that is required to ensure the XY Chart receives data anytime the Serial Publisher publishes. The XY Chart is built to store subcription data in a way that makes it easy specify which of that data you want to plot. It is perhaps worth noting that underneath the hood, as with essentially any publish-subscribe implementation, all subscribers end up in a “publish to” list in the publisher, which can then send copies of its data to publish to each subscribing plugin.
When plugins are developed for JADE, they decide whether they publish data or subscribe to data. Some plugins may neither publish nor subscribe to data, and others may both publish and subscribe. Such choices are left to the developer of the plugin and are generally made based on the purpose of the plugin. That said, some plugins are quite generalized and allow for configurably sending messages. For exmaple, the State Machine plugin allows you to implement an arbitrary state machine, while allowing you to optionally send messages in each state. It can subscribe to data from the outside for use within the state machine definition and messages can be sent to specific plugins or be published to all subscribers of the state machine. There’s more to the state machine story but the idea here is that it represents an exmaple of where messages may be sent based on the logic you specify in a plugin’s configuration.
Importantly, we should only specify (or add plugin instance names to) the subscribesTo configuration for plugins which do actually handle incoming subscription data. Otherwise the publisher will begin filling up a would-be subscriber’s message queue, which would constitute a memory leak. In short, only plugins which are built to actually handle subscriptions should specify the subscribesTo configuration element. And for good measure, we shouldn’t subscribe to more plugins than we need (i.e. only if we use the data should we subscribe), in order to eliminate superfluous data from flowing around the system.
Workers also publish plugin status information to any subscribers. To subscribe to this data, simply use PLUGIN_INFO in the subscribesTo array for any plugin which handles such data. For more information on this published data, see The Worker documentation.
So, we now understand that a publishing plugin will publish copies of data (or send messages, if you prefer that semantic) to all plugins which have subscribed to it. But what about sending a specific message to a specific plugin? Do plugins handle any messages, perhaps for controlling their behavior? Well, the answer to the latter question is: yes. One example is the Relay Manager, which accepts messages to turn on/off the relays it manages. In fact, the State Machine plugin we mentioned above might bre configured to send such a message to a Relay Manager plugin instance, based on monitoring conditions of the system and ultimately determining whether relays should be on or off. Generally, the messages supported by a given plugin will be detailed in the documentation for that plugin. Our main point here is to distinguish the notion of publishing (sending data to a bunch of configured subscribers) from the notion of sending messages point-to-point to a plugin (often as a control message to change how the plugin behaves).
Messages can be sent to the Worker in order to control the state of the running application / program. For details on the messages which can be sent to a Worker, see The Worker documentation.